Computer users often change the computers because of hardware failures, upgrades to newer hardware, and the like. In such situations, a user usually wishes to transfer custom changes made on one computer to the next to reduce loss of productivity. These changes, collectively referred to as user state, include the user's documents and the changes he or she has made to operating system and application settings.
Computer administrators are normally charged with the task of gathering the user state for future restoration on a replacement computer or upgraded computer. Generally, script driven migration tools are available but require an administrator to identify the location of files and registry keys that make up the user state. Once the administrator provides the required location information to the migration tool, the tool gathers the files and registry keys for the administrator.
However, it can be difficult for an administrator to identify the location of application settings because there is no standard location for storing them. In other words, each application determines the storage location of its settings. The typical storage locations of application settings include a central database of the operating system (e.g., the registry) or a file system of the computer. Also, there is no easy way to distinguish the settings of an application from other information, so even exhaustive searches of the central database or the file system will not necessarily yield the required information. Typically, because of all the uncertainty, the migration of application settings is a difficult and time consuming process.
One approach to migrating application settings requires the administrator to author a separate migration script for each application to be migrated. Given that authoring migration scripts is not easy (as discussed in the previous paragraph) and that typical enterprises have hundreds if not thousands of distinct applications whose settings are to be migrated, this approach is clearly not scalable. As a compromise, most administrators usually end up migrating the settings of applications supported out of the box by the migration tool and author extra scripts for the most important subset of their enterprise applications. Unfortunately, the rest of the application settings are simply not migrated.
Another approach is to copy all setting from the central database and the file system directories associated with the applications. However, in addition to migrating the required settings, this approach will migrate the settings of applications that should not be migrated as well (e.g., applications that have been previously removed from the source computer or applications that will not be installed on the new computer). Also, machine specific information such as settings of operating system components would also be migrated causing the destination computer to be improperly configured. For example, suppose the database contains the user's file type-to-application mapping (e.g., the information that .wav files should be opened with a particular audio player). If this setting is migrated and the particular audio player is not installed on the destination computer, opening a .wav file on the destination computer would produce undesirable results.